System and method for providing universal serial bus link power management policies in a processor environment

ABSTRACT

One particular example implementation may include an apparatus that includes logic, at least a portion of which is in hardware, the logic configured to: determine that a first device maintains a link to a platform in a selective suspend state; assign a first latency value to the first device; identify at least one user detectable artifact when a second device exits the selective suspend state; and assign, to the second device, a second latency value that is different from the first value.

TECHNICAL FIELD

Embodiments described herein generally relate to providing for powersavings in a processor environment.

BACKGROUND

As electronic devices become more complex and ubiquitous in the everydaylives of users, more and more diverse requirements are placed upon them.For example, many electronic devices can operate on battery power, thusallowing users to operate these devices in many different circumstances.In addition, as capabilities of electronic devices become moreextensive, many users may become reliant on the enhanced performancesuch capabilities provide. As these aspects of electronic devices haveevolved, there has become an increasing need for power optimization sothat users may enjoy longer battery life. However, under manycircumstances, power optimization may sacrifice performance. Therefore,it will be highly beneficial for a user to be able to have the desiredperformance when it matters the most to them, and to have poweroptimization during circumstances (e.g., idle and semi-idle scenarios)where performance may be less important to them.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments are illustrated by way of example and not by way oflimitation in the FIGURES of the accompanying drawings, in which likereferences indicate similar elements and in which:

FIG. 1 is a simplified block diagram illustrating an embodiment of anelectronic device, in accordance with one embodiment of the presentdisclosure;

FIG. 2 illustrates, for one embodiment, an example flow diagram inaccordance with one embodiment of the present disclosure;

FIG. 3 is a simplified time diagram illustrating possible exampledetails associated with the communication system;

FIG. 4 is a is a simplified time diagram illustrating possible exampledetails associated with the communication system;

FIG. 5 is a simplified time diagram illustrating possible exampledetails associated with the communication system;

FIG. 6 is a simplified block diagram associated with an example ARMecosystem system on chip (SOC) of the present disclosure; and

FIG. 7 is a simplified block diagram illustrating example logic that maybe used to execute activities associated with the present disclosure.

The FIGURES of the drawings are not necessarily drawn to scale orproportion, as their dimensions, arrangements, and specifications can bevaried considerably without departing from the scope of the presentdisclosure.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

The following detailed description sets forth example embodiments ofapparatuses, methods, and systems relating to providing a power savingsin a processor environment. Features such as structure(s), function(s),and/or characteristic(s), for example, are described with reference toone embodiment as a matter of convenience; various embodiments may beimplemented with any suitable one or more of the described features.

FIG. 1 is a block diagram illustrating component interaction of anplatform 10 according to at least one example embodiment. The examplesof FIG. 1 are merely examples of component interaction, and do not limitthe scope of the claims. For example, operations attributed to acomponent may vary, number of components may vary, composition of acomponent may vary, and/or the like. For example, in some exampleembodiments, operations attributable to one component of the example ofFIG. 1 may be allocated to one or more other components.

FIG. 1 is a block diagram of a platform 10 in accordance with variousembodiments. On a general level, the concepts presented herein (incertain example embodiments) address device implementation and whichpolicies the device chooses. In various embodiments, platform 10 may beused in a computing device, which may be, for example, a laptop, a cellphone, a personal computer, a personal digital assistant, a palmtop, aset-top box, or any other appropriate type of computing device. Invarious embodiments, platform 10 may be used in a mobile computingdevice.

In at least one example embodiment, platform 10 may include a platformmanagement controller 12, a universal serial bus (USB) host controller14, a plurality of devices 16 a-c, and a platform power managementcontroller 18. More generally, platform 10 may include any suitable USBsystem and device driver stack. Devices 16 a-c are connected to USB hostcontroller 14 through a USB port. Devices 16 a-c are compatible withvarious versions of the USB standard (e.g., USB 2.0 (USB2), 3.0, etc.).The USB 2.0 Specification was released in April 2000. Additionally, thepresent disclosure may be applicable to any other version of the USBSpecification. In various embodiments, the components of platform 10 mayalso include one or more controllers configured to control one or moredevices/functions in the computing device, including but not limited to,a memory controller, an Ethernet controller, a graphics controller, ahard disk controller (HDD), an audio controller, Advanced HostController Interface (AHCI), etc. In various embodiments, the componentsof platform 10 may also include one or more software applicationsrunning on the computing device, one or more device drivers, anoperating system, etc. Platform management controller 12 may be a chip,a host CPU, an expansion card, a stand-alone device that interfaces witha peripheral device, a plug in board, a single integrated circuit on themotherboard, an external device, etc.

Current platforms exhibit enough activity from multiple sources thatwould preclude the platform from doing efficient power management. Ifdevices were able to coalesce activity by intelligent buffering anddeferring non-critical events, and align activity to other platformevents such that all activity occurs in bursts with long periods ofidleness in between, the platform would be able to use deeper powermanagement states during these idle periods.

The USB2 Specification relates to a polled bus. When the device has nodata to move, the device will continue to be polled if there aretransactions pending at the host controller. The USB 2.0 suspend statecan save power on the USB link, but it is difficult to use dynamicallydue to limitations. For example, it takes considerable time to enter andexit the suspend state (three (3) milliseconds (ms)+Operating System(OS) overhead for entry and thirty (30) ms+OS overhead for exit), anddevices are restricted on how much power they can consume in this state.A Link Power Management (LPM) L1 state, is a state that attempts toaddress the deficiencies of the suspend state. An LPM L1 ECN to the USB2Specification was introduced in 2007.

LPM formally defines four power management states for USB devices, L0(on), L1 (sleep with a finer granularity than L2), L2 (suspend), and L3(off). The L1 sleep state differs from the L2 suspend state in that inthe L1 state, the transitional latencies are much shorter than the L2state and there are no explicit power draw requirements in the LPM L1state. The low-latency LPM L1 state is intended to be used dynamicallywhen a device is operational (e.g., in an Advanced Configuration andPower Interface (ACM) D0 state, described below), but otherwise idle andable to quickly enter and exit this low power state without disruptingnormal operation. It is backward compatible in that a new host candetermine whether a device supports a LPM L1 state and can only be usedif the device acknowledges support for this feature.

Note that the present disclosure can be applicable to ACPI™ Revision5.0, released in November 2011. Additionally, the present disclosure isapplicable to any other version of the ACPI™ Specification. Device powerstates, for example under the ACPI standard, may be referred to asD-level states. Power state D0 is associated with the device being fullyon and in an operating state. Power state D0 may be associated with anabsence of power or thermal savings, and may be referred to as anoperation mode.

Power states D1 and D2 may be associated with intermediate power-stateswhose definition varies by device. Device power state D1 is thehighest-powered device low-power state. The power consumption in a D1state is less than in the D0 state but greater than or equal to that inthe D2 state. Frequently, D1 is a clock-gated state in which the devicereceives just enough power to preserve the device's hardware context.Typically, the specification for a bus or device class that supports D1describes this state in more detail. Regarding the device context,generally the device context is preserved by the hardware and need notbe restored by the driver. The specification for a bus or device classthat supports D1 typically provides detailed requirements for preservingthis context. The device driver behavior should save and restore orreinitialize any context lost by the hardware. Typically, however,devices lose little context upon entering this state. The restore time(the time required to restore the device to D0 from D1) should be lessthan restoration from D2 to D0. Typically, devices that use D1 do sobecause resuming from this state does not require the driver to restorethe device's full hardware context.

Power state D2 is an intermediate device low-power state where powerconsumption is less than or equal to that in the D1 state. In general,most device context is lost by the hardware when in a D2 state.Frequently, the state preserves the part of the context that is used tosignal wake events. The specification for a bus or device class thatsupports D2 typically provides detailed requirements for preserving thiscontext. A typical device loses most context when it enters D2 andtherefore, device drivers should save and restore or reinitialize anycontext lost by the hardware. The restore time from D2 to D0 takes atleast as long as restoring the device from D1 to D0. Typically, driversthat support D2 do so because their devices cannot support a wake fromD3. For these devices, power consumption in the D2 state drops to thelowest level from which the device can recover in response to a wakesignal. In contrast to the D1 state, which is implemented to reduce thedelay perceived by the user, the goal in implementing the D2 state is toconserve power. As a result, the restore time from D2 to D0 typicallyexceeds that from D1 to D0. In the D2 state, for example, reduced poweron the bus might cause a device to turn off some of its functionality,thus requiring additional time to restart and restore the device. Manyclasses of device do not define a D2 state.

Power State D3 has the device powered off and unresponsive to its bus.The D3 state may be referred to as a sleep state. The D3 state can befurther divided into two sub-states, D3-hot and D3-cold. When a deviceis in a D3-hot state, the device has auxiliary power. When the device isin a D3-cold state, the device does not have any (or very little) powerprovided. A device in D3-hot can assert power management requests totransition to higher power states. It should be understood that devicepower states may be further divided into sub-states that vary in powersavings and recovery latency.

Programs may communicate regarding power states by using informationindicating power state information. For example, there may be avariable, a message parameter, and/or the like that comprisesinformation that indicates a power state. In addition, there may be avariable, a message parameter, and/or the like, that comprisesinformation indicating a power state limitation. A power statelimitation may be a limitation that restricts a power state that adevice is allowed to enter. For example, a power state limitation may bea limitation that the power state should be no greater than D2, thusprecluding power state D3. In at least one example embodiment, the powerstate limitation may apply to the ACPI standard. In such an embodiment,the power state limitation may constrain D-level settings.

Even though sleep power states described herein relate to the ACPISpecification, it should be understood that the ACPI is merely anexample of a power management scheme that may be utilized to managepower in a processor or a system. Therefore, direct references tospecific elements of the ACPI do not limit the claims, unless suchspecific elements are expressly incorporated into the claims.

System power states, under the ACPI standard, may be referred to asS-level states. Power state S0 (or G0) is associated with normaloperation of the system. Power state S0 may be associated with absenceof power or thermal savings. Power state S0 may be referred to as aworking mode. Power States S1-S4 relate to various depths of sleep-basedpower saving. Power state S1 may be associated with a power saving statefor which instruction execution may restart with the lowest recoverylatency of the S1-S4 states, but with the lowest power saving of theS1-S4 states. Power state S1 may involve flushing processor caches,terminating processor execution, retaining power to RAM and theprocessor, and reducing power to devices in the system that fail toindicate a need to avoid reduced power. Power state S1 may be referredto as a stop-processing mode. Power state S2 may be associated with apower saving state for which instruction execution may restart with alonger recovery latency than the S1 state, but with the greater powersaving than the S1 state. Beyond the power saving actions of S1, powerstate S2 may involve powering off the processor and flushing the dirtycache to RAM. Power state S2 may be referred to as a processing-offmode.

Power state S3 may be associated with a power saving state for whichinstruction execution may restart with a longer recovery latency thanthe S2 state, but with the greater power saving than the S2 state.Beyond the power saving actions of S2, power state S3 may involvepowering off all components except a real time clock and memory, whichmay operate at a reduced power level. Power state S3 may be referred toas a standby mode. Power state S4 may be associated with a power savingstate for which instruction execution may restart with a longer recoverylatency than the S3 state, but with the greater power saving than the S3state. Beyond the power saving actions of S3, power state S4 may involvestoring volatile memory contents to non-volatile memory and terminatingpower to memory. Power state S4 may be referred to as a hibernationmode. Power state S5 may be associated with a power saving state thatavoids saving system context information. Power state S5 may beterminated by pressing a power button. Power state S5 may be referred toas a soft-off mode.

Programs may communicate regarding system power state by usinginformation indicating power state information. For example, there maybe a variable, a message parameter, and/or the like that comprisesinformation that indicates a power state. In addition, there may be avariable, a message parameter, and/or the like, that comprisesinformation indicating a power state limitation. A power statelimitation may be a limitation that restricts a power state that thesystem is allowed to enter. For example, a power state limitation may bea limitation that the power state should be no greater than S2, thusprecluding power states S3, S4, and S5. In at least one exampleembodiment, the power state limitation may apply to the ACPI standard.In such an embodiment, the power state limitation may constrain S-levelsettings.

In current platforms, the only low power LPM state supported by USB2devices is selective suspend. This feature allows a USB device driver(that supports selective suspend) to put the link (of the USB device itcontrols) into selective suspend when the device is idle. When thedevice is no longer idle and is to be used again, the system wakes thedevice and resumes normal operation. The USB Specification also definesan additional low power feature call remote wakeup. This feature, ifsupported by the USB device, allows the USB device to wake itself fromselective suspend. This allows a device specific event to resume thesystem instead of the system resuming the device.

However, the exit latency from a selective suspend is fairly large and,further, many devices in categories like communication devices, humaninterface devices (HIDs), etc., do not have high selective suspendresidency. Power is expended both by the device and by other platformcomponents (e.g., like the host controller when the USB link is kept inlink power management (LPM) L0 state). Putting the link in to alow-power LPM L1 state allows power savings on both sides of the link.

The LPM L1 state implicitly conveys this to the platform whether thedevice is idle. Link states (such as SATA Partial and Slumber states,USB2 LPM L1 and suspend states) can be translated into latencyrequirements by host controller 14 and sent to platform power managementcontroller 18. Platform power management controller 18 can use theselatency requirements to determine how deeply to power manage variousplatform components without undermining the performance of the device,quality of service requirements, etc.

An LPM L1 ECN in the USB2 specification (introduced in 2007) defines aparameter called Best Effort Service Latency (BESL), which can be usedby the host controller to provide latency requirements. The value ofBESL indicates the best effort to resumption of service to the deviceafter the initiation of a resume event from LPM L1 state to L0. It canreflect the point in time after a resume start to the start oftransactions to a device endpoint. The time is not a guarantee, but abest effort that will be made by the host to service the device by thattime. A larger BESL value translates to larger latency requirements sentby host controller 14 to platform power management controller 18, andallows deeper power savings on both the host and the device side, ascomponents on both sides have more time to exit from the deeper lowpower states. However, choosing a fixed BESL value (which may be thesimplest implementation) is not the most optimal for platform powerconsumption.

An LPM L1 implementation and BESL selection in a device can be done inmany ways based on device requirements. For instance, a communicationdevice like a WWAN or WLAN device moves much more data to (or from) ahost platform and, further, it is more sensitive to latency due tobuffering constraints compared to a HID. Some other devices (likedigital cameras) keep their links in selective suspend when not in useand, further, would utilize LPM L1 only when active for periods ofinactivity between bursts of data movement. They are not sensitive tothe selective suspend exit latency when transitioning from idle toactive.

The USB2.0 LPM L1 ECN errata (September 2011) enables a USB2.0 device tocommunicate (to the host) its preferred BESL and BESLD values in theUSB2.0 extension descriptor. Device implementations may select a subsetof specific design points for optimization within the full range. Therecommended use of these fields is that the baseline BESL field can havea value less than the deep BESL field. The expected use is the baselineBESL value communicates a nominal power savings design point and thedeep BESL value communicates a significant power savings design point.

In one example, the USB device driver may know that the device is adigital camera and can send a message to USB host controller 14 to keepthe link to the device in a selective suspend state when the device isnot in use, and in a LPM L0 state when the device is in use. In the idleperiod between bursts of activity, USB host controller 14 can attempt toput the link into a low power LPM L1 state with a BESL of about fourhundred (400) us (or whatever optimal BESL value was indicated by thedevice). The BESL time accounts for the duration before data transferfrom device can be resumed, and is used to set the appropriate bufferwatermark thresholds so that there are no buffer overruns.

In another example, the USB device driver may know that the device is anetwork data device, where the exit latency from selective suspend maycause buffer overruns or underruns, and/or an associated loss ofperformance. In this example, the USB device driver may not direct USBhost controller 14 to keep the link to the device in a selective suspendstate when connected to the network even when the device ispredominantly idle. Since in many usage models, platforms are alwaysconnected to the network, for optimal power savings the networkingdevice should support two BESL values and indicate the two values to thehost controller (e.g., via the USB2.0 extension descriptor). When linkis idle, USB host controller 14 can attempt to put the link to thedevice into an LPM L1 state with a deep BESL value of about 5 msec andif the device returns a NYET response, then re-try the L1 entry with aBESL value of about 400 usec. The device can ACK the L1 entry with BESLvalue of about 400 usec between idle periods of data movement and ACKentry into an LPM L1 state with a BESL of about five (5) ms when thedevice is connected (but very idle).

In yet another example, the USB device driver may know that the deviceis a USB2.0 device, where the exit latency from selective suspend maycause user detectable artifacts, such as with a HID (e.g., a mouse ortouch controller). In this example, USB host controller 14 cannot keepthe link to the device in a selective suspend state when the device isidle. In a device like a USB2.0 mouse for example, the idle to activetransition may show up as in jerky mouse movement on the screen due tolarge exit latencies from selective suspend. However, such an HID devicecan easily tolerate a latency of about 5 msec without any visibleartifacts. For optimal power savings, an HID device can indicate that itsupports a BESL value of around 5 msec to USB host controller 14 (e.g.,via the USB2.0 extension descriptor). The USB host controller willtransition the link to the device into an LPM L1 state with a BESL ofabout three (3) ms to about five (5) ms between periods of inactivity.By recognizing the latency requirements of each device and what devicesare sensitive to, the selective suspend exit latency, a low power linkstate can be used for each device such that each device can enter andexit a low power state without disrupting normal operations.

Turning to FIG. 2, FIG. 2 is a simplified flowchart 200 illustrating onepotential operation associated with the present disclosure. The flowgenerally indicates which LPM L1 policies a device should implementbased on the device's latency requirements, amount of data movement,buffering constraints, frequency of data movement, selective suspendresidency, etc. At 202, a device is connected to a system. At 204, thedevice determines if it can keep the link to the system in a selectivesuspend state when the device is not in use and in a link powermanagement L0 state due to stringent latency requirements when thedevice is in use. If so, the device can support LPM state with a BESL ofabout 100 to four hundred (400) microseconds (us) for periods ofinactivity between bursts of data movement or when waiting for a timeoutto go to a selective suspend state, as in 206.

At 208, the device determines if it does not have stringent latencyrequirements when active as in 204, and if the exit latency from theselective suspend state causes user detectable artifacts precluding useof selective suspend when idle. If so, the device can support link powermanagement L1 state with a BESL of between about three (3) to about five(5) milliseconds (ms) for periods of inactivity when there is no datamovement, as in 210.

At 212, the device determines if the exit latency from the selectivesuspend state causes device buffer overruns, buffer underruns, and/or anassociated loss of performance. Such a device (e.g., a networkingdevice) is generally in use when connected to the network and cannottransition to the selective suspend due to buffering constraints andlatency requirements. The device can enter an LPM L1 state with a BESLof about four hundred (400) us for periods of inactivity between datamovement and enter into an LPM L1 state with a BESL of between aboutthree (3) to about five (5) ms when the device is determined to be veryidle, as in 214. If the device determines that it is rarely used and thelink selective suspend residency is high, then the LPM L1 state is notrequired for the device, as in 216.

Turning to FIG. 3, FIG. 3 is a simplified block diagram illustrating onepossible set of details according to at least one example embodiment.The examples of FIG. 3 are merely examples of an electronicconfiguration, and do not limit the scope of the claims. For example,the number of electrical components may vary, the placement of theelectrical components may vary, operations attributed to a softwarecomponent may vary, number of software components may vary, compositionof a software component may vary, and/or the like. This particularconfiguration includes device data 24.

Device data 24 and the illustrative examples are only used forillustrative purposes. Device data 24 may be any data that is collectedor used by a device (e.g., device 16 a) that keeps a link to a hostcontroller (e.g., USB host controller 14) in a selective suspend statewhen not in use and in a LPM L0 state when the link is in use (e.g.,digital camera, secure digital (SD) card reader, television tuner,etc.). Device 16 a includes one or more buffers (buffers 26 a-26 c eachmay be the same buffer at a different point in time and are shown toillustrate the passage of time). As device data 24 is collected bydevice 16 a, the data is placed into one or more buffers and each bufferhas a known capacity (e.g., buffer 26 a is shown to hold about 10 msecof data). A high watermark may be used such that when the amount of datain the buffer reaches a certain level, a wake signal (e.g., wake signal32 a) is sent to USB host controller 14.

The wake signal is sent in sufficient time to allow transition from alow power state to an active state so the data may be flushed from thebuffer before any overruns occur. For example, before the wake signal issent, USB host controller 14 may be in a LPM L1 state (e.g., LPM L1state 34 a). After receiving wake signal 32 a, the USB link transitionsinto an active state (e.g., L0 state 36 a) and data transfers areinitiated by USB host controller 14 within BESL time indicated in theLPM L1 token. This guarantees predictable behavior and the devices canappropriately design the buffer watermarks to avoid buffer overruns.After the data (e.g., data 28 a) has been received, USB host controller14 can enter into another LPM L1 state (e.g., LPM L1 state 34 b) forsome period of inactivity. If device data 24 includes frames, an end offrame indicator 30 may be used to identify the end of a frame. When endof frame indicator 30 is detected, the platform processor core (CPU) maywake out of a low power state (e.g., Cx state 38 a described below) andenter into an active state (e.g., C0 state 40) to execute code andreceive the frame data. Once the frame data has been received, CPU 15and platform processor may enter into another low power state (e.g., Cxstate 38 b).

The ACPI Specification defines the CPU C-states power management states.CPU operating states (C-states) are the capability of an idle processorto turn off unused components to save power. When a processor runs inthe C0 state, it is working. A processor running in any other C-state isidle. Higher C-state numbers represent deeper CPU sleep states. Athigher C-states, more components shut down to save power. Somecomponents that are shut down include stopping the processor clock andstopping interrupts. A disadvantage is that deeper sleep states havelarger wake up times.

Turning to FIG. 4, FIG. 4 is a simplified block diagram illustrating onepossible set of details according to at least one example embodiment.The examples of FIG. 4 are merely examples of an electronicconfiguration, and do not limit the scope of the claims. For example,the number of electrical components may vary, the placement of theelectrical components may vary, operations attributed to a softwarecomponent may vary, number of software components may vary, compositionof a software component may vary, and/or the like. This particularconfiguration includes device 16 c. Device 16 c is a USB2.0 humaninterface device (HID) where the exit latency from selective suspend maycause user detectable artifacts, such as with a mouse or touchcontroller.

HID devices typically use Interrupt Endpoints for data movement. At thepoll interval, device 16 c receives an IN Token 54 a from the USB hostcontroller 14 on its interrupt endpoint. If the device has data to send,it sends the data 56 a to the USB host controller 14. In FIG. 4, the USBhost controller keeps the link in L0 58 a until the next poll 54 b. Inanother embodiment, the host controller may put the link into LPM L1 andbring the link back to L0 just before the next poll 54 b. Then thedevice 56 a receives another IN Token 54 b on its interrupt endpoint butthis time instead of data sends a negative acknowledgement (NAK) signal60 as it has no data to send. NAK signal 60 causes USB host controller14 to send a low power LPM L1 Token request signal 62. In response toLPM L1 Token request signal 62, an ACK signal 64 is sent by the device16 c and the link enters into a lower power LPM L1 state 66. The linkstays in the LPM L1 state until there is new data from device 16 c thatneeds to be sent to the host e.g. mouse click or movement. At such atime, the device 16 c will initiate a L1 exit 68. The link willtransition to L0 58 b and the host controller will start polling thedevice again 54 c. The poll will occur before poll interval duration orBESL, bound by the larger of the two. The device sends data to hostcontroller 54 b. In one example (not shown), device may receive a secondNAK signal which would cause device 16 c to enter into another low powerstate.

Turning to FIG. 5, FIG. 5 is a simplified block diagram illustrating onepossible set of details according to at least one example embodiment.The examples of FIG. 5 are merely examples of an electronicconfiguration, and do not limit the scope of the claims. For example,the number of electrical components may vary, the placement of theelectrical components may vary, operations attributed to a softwarecomponent may vary, number of software components may vary, compositionof a software component may vary, and/or the like. This particularconfiguration includes device data 44.

Device data 44 and the illustrative examples are only used forillustrative purposes. Device data 44 may be any data that is collectedor used by a device (e.g., device 16 b) where the exit latency fromselective suspend may cause buffer overruns or underruns and/or anassociated loss of performance. An example of such a device would be awireless networking device like a WLAN or WWAN device. Device 16 bincludes a buffer (buffers 46 a and 46 c each may be the same buffer ata different point in time and are shown to illustrate the passage oftime). As device data 44 is collected by device 16 b, the data is placedinto one or more buffers and each buffer has a known capacity (e.g.,buffer 26 a is shown to hold about 2 ms of data). A high watermark maybe used such that when the amount of data in the buffer reaches acertain level, a wake signal (e.g., wake signal 50 a) is sent to USBhost controller 14. The wake signal is sent in sufficient time to allowtransition from a low power state to an active state so the data may beflushed from the buffer before any buffer overruns occur. In thisparticular example, before the wake signal was sent, USB host controller14 may be in a LPM L1 state (e.g., LPM L1 state 34 a). After receivingwake signal 50 a, the link is transitioned into an active state (e.g.,L0 state 36 a) and data transfers are initiated by the USB hostcontroller 14 within BESL time indicated in the LPM L1 token. After thedata (e.g., data 48 a) has been received, USB host controller 14 canenter into another LPM L1 state (LPM L1 state 34 b) after a certaininactivity timeout.

For optimal power savings, such a networking device which is nearlyalways connected to the network would support two values of BESL; asmaller value for LPM L1 state during bursts of data transfers and alarger BESL value for LPM L1 state when predominantly idle.

In an embodiment, USB host controller 14 sends a first BESL value (e.g.,three (3) ms). If device 16 b is receiving data or is otherwise somewhatactive where the radio is on in case of wireless devices and there arechances of data being received over the wireless network, the first BESLvalue can be rejected. Upon rejection (NYET) of the LPM L1 Token withfirst BESL value, a second LPM L1 token with lower BESL value can besent (e.g., two hundred (200) us).

After some period of no network activity 44, the device 16 b may use anidle timeout 52 to power off its radio. At this time, the device 16 binitiates a LPM L1 Wake if link is in LPM L1 and the link istransitioned to L0 42. When the USB host controller 14 attempts the LPML1 entry with BESL value of 3 msec, the device 16 b may safely acceptLPM L1 token and the link transitions to LPM L1 34. As the radio is off,there can be no risk of buffer overflows.

FIG. 6 is a simplified block diagram associated with an example ARMecosystem SOC 600 of the present disclosure. At least one exampleimplementation of the present disclosure includes an integration of thepower savings features discussed herein and an ARM component. Forexample, the example of FIG. 6 can be associated with any ARM core(e.g., A-9, A-15, etc.). Further, the architecture can be part of anytype of tablet, smartphone (inclusive of Android™ phones, i-Phones™),i-Pad™, Google Nexus™, Microsoft Surface™, personal computer, server,video processing components, laptop computer (inclusive of any type ofnotebook), Ultrabook™, any type of touch-enabled input device, etc.

In this example of FIG. 6, ARM ecosystem SOC 600 may include multiplecores 606-607, an L2 cache control 608, a bus interface unit 609, an L2cache 610, a graphics processing unit (GPU) 615, an interconnect 602, avideo codec 620, and a liquid crystal display (LCD) I/F 625, which maybe associated with mobile industry processor interface(MIPI)/high-definition multimedia interface (HDMI) links that couple toan LDC.

ARM ecosystem SOC 600 may also include a subscriber identity module(SIM) I/F 630, a boot read-only memory (ROM) 635, a synchronous dynamicrandom access memory (SDRAM) controller 640, a flash controller 645, aserial peripheral interface (SPI) master or USB host controller 650, asuitable power control 655, a dynamic RAM (DRAM) 660, and flash 665. Inaddition, one or more example embodiment include one or morecommunication capabilities, interfaces, and features such as instancesof Bluetooth 670, a 3G modem 675, a global positioning system (GPS) 680,and an 802.11 WiFi 785.

In operation, the example of FIG. 6 can offer processing capabilities,along with relatively low power consumption to enable computing ofvarious types (e.g., mobile computing, high-end digital home, servers,wireless infrastructure, etc.). In addition, such an architecture canenable any number of software applications (e.g., Android™, Adobe®Flash® Player, Java Platform Standard Edition (Java SE), JavaFX, Linux,Microsoft Windows Embedded, Symbian and Ubuntu, etc.). In at least oneexample embodiment, the core processor may implement an out-of-ordersuperscalar pipeline with a coupled low-latency level-2 cache.

FIG. 7 is a simplified block diagram illustrating potential electronicsand logic that may be associated with any of the power saving operationsdiscussed herein. In at least one example embodiment, system 700includes a touch controller 702, one or more processors 704, systemcontrol logic 706 coupled to at least one of processor(s) 704, systemmemory 708 coupled to system control logic 706, non-volatile memoryand/or storage device(s) 710 coupled to system control logic 706,display controller 712 coupled to system control logic 706, displaycontroller 712 coupled to a display, power management controller 718coupled to system control logic 706, and/or communication interfaces 716coupled to system control logic 706.

System control logic 706, in at least one embodiment, includes anysuitable interface controllers to provide for any suitable interface toat least one processor 704 and/or to any suitable device or component incommunication with system control logic 706. System control logic 706,in at least one example embodiment, includes one or more memorycontrollers to provide an interface to system memory 708. System memory708 may be used to load and store data and/or instructions, for example,for system 700. System memory 708, in at least one example embodiment,includes any suitable volatile memory, such as suitable dynamic randomaccess memory (DRAM) for example. System control logic 706, in at leastone example embodiment, includes one or more I/O controllers to providean interface to a display device, touch controller 702, and non-volatilememory and/or storage device(s) 710.

Non-volatile memory and/or storage device(s) 710 may be used to storedata and/or instructions, for example within software 728. Non-volatilememory and/or storage device(s) 710 may include any suitablenon-volatile memory, such as flash memory for example, and/or mayinclude any suitable non-volatile storage device(s), such as one or morehard disc drives (HDDs), one or more compact disc (CD) drives, and/orone or more digital versatile disc (DVD) drives for example.

Power management controller 718 may include power management logic 730configured to control various power management and/or power savingfunctions disclosed herein or any part thereof. In at least one exampleembodiment, power management controller 718 is configured to reduce thepower consumption of components or devices of system 700 that may eitherbe operated at reduced power or turned off when the electronic device isin a closed configuration. For example, in at least one exampleembodiment, when the electronic device is in a closed configuration,power management controller 718 performs one or more of the following:power down the unused portion of the display and/or any backlightassociated therewith; allow one or more of processor(s) 704 to go to alower power state if less computing power is required in the closedconfiguration; and shutdown any devices and/or components, such as akeyboard, that are unused when an electronic device is in the closedconfiguration.

Communications interface(s) 720 may provide an interface for system 700to communicate over one or more networks and/or with any other suitabledevice. Communications interface(s) 720 may include any suitablehardware and/or firmware. Communications interface(s) 720, in at leastone example embodiment, may include, for example, a network adapter, awireless network adapter, a telephone modem, and/or a wireless modem.

System control logic 706, in at least one example embodiment, includesone or more I/O controllers to provide an interface to any suitableinput/output device(s) such as, for example, an audio device to helpconvert sound into corresponding digital signals and/or to help convertdigital signals into corresponding sound, a camera, a camcorder, aprinter, and/or a scanner.

For at least one example embodiment, at least one processor 704 may bepackaged together with logic for one or more controllers of systemcontrol logic 706. In at least one example embodiment, at least oneprocessor 704 may be packaged together with logic for one or morecontrollers of system control logic 706 to form a System in Package(SiP). In at least one example embodiment, at least one processor 704may be integrated on the same die with logic for one or more controllersof system control logic 706. For at least one example embodiment, atleast one processor 704 may be integrated on the same die with logic forone or more controllers of system control logic 706 to form a System onChip (SoC).

For touch control, touch controller 702 may include touch sensorinterface circuitry 722 and touch control logic 724. Touch sensorinterface circuitry 722 may be coupled to detect touch input over afirst touch surface layer and a second touch surface layer of a display(i.e., display device 710). Touch sensor interface circuitry 722 mayinclude any suitable circuitry that may depend, for example, at least inpart on the touch-sensitive technology used for a touch input device.Touch sensor interface circuitry 722, in one embodiment, may support anysuitable multi-touch technology. Touch sensor interface circuitry 722,in at least one embodiment, includes any suitable circuitry to convertanalog signals corresponding to a first touch surface layer and a secondsurface layer into any suitable digital touch input data. Suitabledigital touch input data for one embodiment may include, for example,touch location or coordinate data.

Touch control logic 724 may be coupled to help control touch sensorinterface circuitry 722 in any suitable manner to detect touch inputover a first touch surface layer and a second touch surface layer. Touchcontrol logic 724 for at least one example embodiment may also becoupled to output in any suitable manner digital touch input datacorresponding to touch input detected by touch sensor interfacecircuitry 722. Touch control logic 724 may be implemented using anysuitable logic, including any suitable hardware, firmware, and/orsoftware logic (e.g., non-transitory tangible media), that may depend,for example, at least in part on the circuitry used for touch sensorinterface circuitry 722. Touch control logic 724 for one embodiment maysupport any suitable multi-touch technology.

Touch control logic 724 may be coupled to output digital touch inputdata to system control logic 706 and/or at least one processor 704 forprocessing. At least one processor 704 for one embodiment may executeany suitable software to process digital touch input data output fromtouch control logic 724. Suitable software may include, for example, anysuitable driver software and/or any suitable application software. Asillustrated in FIG. 7, system memory 708 may store suitable software 726and/or non-volatile memory and/or storage device(s).

Note that in some example implementations, the functions outlined hereinmay be implemented in conjunction with logic that is encoded in one ormore tangible, non-transitory media (e.g., embedded logic provided in anapplication-specific integrated circuit (ASIC), in digital signalprocessor (DSP) instructions, software [potentially inclusive of objectcode and source code] to be executed by a processor, or other similarmachine, etc.). In some of these instances, memory elements can storedata used for the operations described herein. This includes the memoryelements being able to store software, logic, code, or processorinstructions that are executed to carry out the activities describedherein. A processor can execute any type of instructions associated withthe data to achieve the operations detailed herein. In one example, theprocessors could transform an element or an article (e.g., data) fromone state or thing to another state or thing. In another example, theactivities outlined herein may be implemented with fixed logic orprogrammable logic (e.g., software/computer instructions executed by aprocessor) and the elements identified herein could be some type of aprogrammable processor, programmable digital logic (e.g., a fieldprogrammable gate array (FPGA), a DSP, an erasable programmable readonly memory (EPROM), electrically erasable programmable read-only memory(EEPROM)) or an ASIC that includes digital logic, software, code,electronic instructions, or any suitable combination thereof.

Note that with the examples provided above, as well as numerous otherexamples provided herein, interaction may be described in terms oflayers, protocols, interfaces, spaces, and environments more generally.However, this has been done for purposes of clarity and example only. Incertain cases, it may be easier to describe one or more of thefunctionalities of a given set of flows by only referencing a limitednumber of components. It should be appreciated that the architecturesdiscussed herein (and its teachings) are readily scalable and canaccommodate a large number of components, as well as morecomplicated/sophisticated arrangements and configurations. Accordingly,the examples provided should not limit the scope or inhibit the broadteachings of the present disclosure, as potentially applied to a myriadof other architectures.

It is also important to note that the blocks in the flow diagramsillustrate only some of the possible signaling scenarios and patternsthat may be executed by, or within, the circuits discussed herein. Someof these blocks may be deleted or removed where appropriate, or thesesteps may be modified or changed considerably without departing from thescope of teachings provided herein. In addition, a number of theseoperations have been described as being executed concurrently with, orin parallel to, one or more additional operations. However, the timingof these operations may be altered considerably. The precedingoperational flows have been offered for purposes of example anddiscussion. Substantial flexibility is provided by the presentdisclosure in that any suitable arrangements, chronologies,configurations, and timing mechanisms may be provided without departingfrom the teachings provided herein.

It is also imperative to note that all of the Specifications, protocols,and relationships outlined herein (e.g., specific commands, timingintervals, supporting ancillary components, etc.) have only been offeredfor purposes of example and teaching only. Each of these data may bevaried considerably without departing from the spirit of the presentdisclosure, or the scope of the appended claims. The specificationsapply to many varying and non-limiting examples and, accordingly, theyshould be construed as such. In the foregoing description, exampleembodiments have been described. Various modifications and changes maybe made to such embodiments without departing from the scope of theappended claims. The description and drawings are, accordingly, to beregarded in an illustrative rather than a restrictive sense.

Numerous other changes, substitutions, variations, alterations, andmodifications may be ascertained to one skilled in the art and it isintended that the present disclosure encompass all such changes,substitutions, variations, alterations, and modifications as fallingwithin the scope of the appended claims. In order to assist the UnitedStates Patent and Trademark Office (USPTO) and, additionally, anyreaders of any patent issued on this application in interpreting theclaims appended hereto, Applicant wishes to note that the Applicant: (a)does not intend any of the appended claims to invoke paragraph six (6)of 35 U.S.C. section 112 as it exists on the date of the filing hereofunless the words “means for” or “step for” are specifically used in theparticular claims; and (b) does not intend, by any statement in theSpecification, to limit this disclosure in any way that is not otherwisereflected in the appended claims.

Example Embodiment Implementations

In at least one particular example implementation, an apparatus mayinclude a means for determining that a first device maintains a link toa platform in a selective suspend state; means for assigning a firstlatency value to the first device; means for identifying at least oneuser detectable artifact when a second device exits the selectivesuspend state; and means for assigning, to the second device, a secondlatency value that is different from the first latency value. The ‘meansfor’ in these instances can include (but is not limited to) using anysuitable processor, software, circuitry, hub, controller, interface,link, bus, communication pathway, etc.

The apparatus may also include means for determining that when a thirddevice exits the selective suspend state, the exit causes a bufferoverrun or a buffer underrun. The second latency value can be betweenapproximately three (3) to five (5) milliseconds (ms). Additionally, thefirst latency value can be a Best Effort Service Latency (BESL) valueindicative of an attempt to service the first device within a designatedtime interval. The first device can include a buffer and the latencyvalue can be dependent on a size of the buffer.

What is claimed is:
 1. An apparatus, comprising: logic, at least aportion of which is in hardware, the logic configured to: determine thata first device maintains a link to a platform in a selective suspendstate; assign a first latency value to the first device; identify atleast one user detectable artifact when a second device exits theselective suspend state; and assign, to the second device, a secondlatency value that is different from the first value.
 2. The apparatusof claim 1, wherein the first latency value is approximately fourhundred (400) microseconds (us).
 3. The apparatus of claim 1, whereinthe second latency value is between approximately three (3) to five (5)milliseconds (ms).
 4. The apparatus of claim 1, wherein the first deviceis a digital camera, a secure digital card reader, or a televisiontuner.
 5. The apparatus of claim 1, wherein the second device is a humaninterface device.
 6. The apparatus of claim 1, wherein the apparatus isfurther configured to: determine that when a third device exits theselective suspend state, the exit causes a buffer overrun or a bufferunderrun.
 7. The apparatus of claim 1, wherein the first latency valueis a Best Effort Service Latency (BESL) value indicative of an attemptto service the first device within a designated time interval.
 8. Theapparatus of claim 1, wherein the first device includes a buffer and thelatency value is dependent on a size of the buffer.
 9. A system,comprising: a device controller; and a platform power managementcontroller, wherein the system is configured for: determining that afirst device maintains a link in a selective suspend state; assigning afirst latency value to the first device; identifying at least one userdetectable artifact when a second device exits the selective suspendstate; and assigning, to the second device, a second latency value thatis different from the first latency value.
 10. The system of claim 9,wherein the first latency value is approximately four hundred (400)microseconds (us).
 11. The system of claim 9, wherein the second latencyvalue is between approximately three (3) to five (5) milliseconds (ms).12. The system of claim 9, wherein the first device is a digital camera,a secure digital card reader, or a television tuner.
 13. The system ofclaim 9, wherein the second device is a human interface device.
 14. Thesystem of claim 9, wherein the system is further configured for:determining that when a third device exits the selective suspend state,the exit causes a buffer overrun or a buffer underrun.
 15. The system ofclaim 9, wherein the first latency value is a Best Effort ServiceLatency (BESL) value indicative of an attempt to service the firstdevice within a designated time interval.
 16. The system of claim 9,wherein the first device includes a buffer and the latency value isdependent on a size of the buffer.
 17. A non-transitory computerreadable medium comprising instructions that, when executed, cause anapparatus to: determine that a first device maintains a link to aplatform in a selective suspend state; assign a first latency value tothe first device; identify at least one user detectable artifact when asecond device exits the selective suspend state; and assign, to thesecond device, a second latency value that is different from the firstvalue.
 18. The computer readable medium of claim 17, wherein the firstlatency value is approximately four hundred (400) microseconds (us). 19.The computer readable medium of claim 17, wherein the second latencyvalue is between approximately three (3) to about five (5) milliseconds(ms).
 20. The computer readable medium of claim 17, wherein the firstdevice is a digital camera, a secure digital card reader, or atelevision tuner.
 21. The computer readable medium of claim 17, whereinthe second device is a human interface device.
 22. The computer readablemedium of claim 17, wherein the apparatus is further configured to:determine that when a third device exits the selective suspend state,the exit causes a buffer overrun or a buffer underrun.
 23. The computerreadable medium of claim 17, wherein the first latency value is a BestEffort Service Latency (BESL) value indicative of an attempt to servicethe first device within a designated time interval.
 24. The computerreadable medium of claim 17, wherein the first device includes a bufferand the latency value is dependent on a size of the buffer.
 25. Anapparatus, comprising: means for determining that a first devicemaintains a link to a platform in a selective suspend state; means forassigning a first latency value to the first device; means foridentifying at least one user detectable artifact when a second deviceexits the selective suspend state; and means for assigning, to thesecond device, a second latency value that is different from the firstlatency value.
 26. The apparatus of claim 25, further comprising: meansfor determining that when a third device exits the selective suspendstate, the exit causes a buffer overrun or a buffer underrun.
 27. Theapparatus of claim 25, wherein the second latency value is betweenapproximately three (3) to five (5) milliseconds (ms).
 28. The apparatusof claim 25, wherein the first device is a digital camera, a securedigital card reader, or a television tuner.
 29. The apparatus of claim25, wherein the second device is a human interface device.
 30. Theapparatus of claim 25, wherein the first latency value is a Best EffortService Latency (BESL) value indicative of an attempt to service thefirst device within a designated time interval, and wherein the firstdevice includes a buffer and the latency value is dependent on a size ofthe buffer.